Chrome fournit une protection contre les tentatives d'hameçonnage depuis longtemps. Une fois toutes les 30 à 60 minutes, le navigateur reçoit une liste à jour des sites considérés comme dangereux. Si l’internaute visite l’un d’entre eux, Chrome affiche un écran rouge pour prévenir du danger.
Cette méthode évolue pour devenir plus réactive. Google explique, dans un billet, que la liste des sites visités est constamment envoyée sur un serveur sous forme d’empreinte chiffrée pour y être comparée avec un répertoire de site dangereux ou potentiellement dangereux.
La société affirme qu’elle ne compare que des hashs et ne sait jamais quels sites sont visités par les internautes. Le serveur de comparaison serait même géré par un tiers (Fastly). Il permettrait de ne jamais réunir l’adresse visitée et l’adresse IP source.
Selon Google, cette méthode devrait entrainer une baisse de 25 % des tentatives d'hameçonnage dans son navigateur. Elle serait beaucoup plus efficace contre des sites ne restant que peu de temps en ligne. La nouvelle méthode est déjà active dans toutes les dernières révisions de Chrome sur l’ensemble des plateformes.
Commentaires (9)
#1
Que l'url du serveur soit maquillée dans un HASH ne signifie pas qu'elle est lisible. C'est d'ailleurs l'objectif de ce système. Ce truc serait réellement anonyme si la liste était traitée en locale. Là concrètement tu envoies en temps réel ton historique de navigation, en face "fastly" a peut-être une table de hash de toutes les entrées DNS du monde, et ne remonte que les "dangereux" tout en loguant l'entièreté de ta navigation.
#1.1
- une requête avec un hash partiel (et le serveur répond avec l'ensemble des hash correspondants)
- une vérification en local par rapport à la liste retournée par le serveur.
Ainsi, le hash complet d'un mot de passe testé n'est jamais envoyé complètement. Pour I have been pwned, 5 caractères suffisent.
[edit]
Je viens de regarder le post de Google, et c'est bien ce qu'ils font ! Donc j'ai rien dit :)
Historique des modifications :
Posté le 18/03/2024 à 08h37
Ou alors il faudrait faire comme l'API de I have been pwned, où cela se passe en 2 temps :
- une requête avec un hash partiel (et le serveur répond avec l'ensemble des hash correspondants)
- une vérification en local par rapport à la liste retournée par le serveur.
Ainsi, le hash complet d'un mot de passe testé n'est jamais envoyé complètement. Pour I have been pwned, 5 caractères suffisent.
[edit]
Je viens de regarder le post de Google, et c'est bien ce qu'ils font ! Donc j'ai rien dit :)
#2
Moi j'ai confiance. C'est pas comme si Google cherchait à récupérer nos historiques coté serveur (Analytics, DNS) ou en local (FLoC, Topics).
/s
Historique des modifications :
Posté le 18/03/2024 à 08h56
Moi j'ai confiance. C'est pas comme si Google cherchait à récupérer nos historiques coté serveur (Analytics, DNS) ou en local avec (FLoC, Topics).
/s
#2.1
#3
#4
Je me demande souvent quelle est la quantité de données utiles face à la quantité de données transférées.
C'est quoi l'image par rapport à la vie quotidienne: des agents en permanence autour de nous pour faire passer un interrogatoire à la boulangère avant qu'on entre, goûter notre sandwich avant qu'on ne puisse l'attraper, vérifier que la salle est sécure avant de s'asseoir, et qui nettoient derrière nous quand on part?
#5
#6
Historique des modifications :
Posté le 18/03/2024 à 20h33
Des milliards de requêtes supplémentaires chaque heure, c'est bon pour l'environnement !
Posté le 18/03/2024 à 20h34
Des milliards de requêtes supplémentaires chaque heure sur le net' c'est bon pour l'environnement !
#6.1